FIG. 1 shows in outline the logical and physical architecture of a bridge 1 for bridging between data links 2 and 3. In this example link 2 carries data according to the Fibrechannel protocol and link 3 carries data according to the ISCSI (Internet Small Computer Serial Interface) protocol over the Ethernet protocol (known as ISCSI-over-Ethernet). The bridge comprises a Fibrechannel hardware interface 4, an Ethernet hardware interface 5 and a data processing section 6. The interfaces link the data processing section to the respective data links 2 and 3. The data processing section implements a series of logical protocol layers: a Fibrechannel driver 7, a Fibrechannel stack 8, a bridge/buffer cache 9, an ISCSI stack 10, a TCP (transmission control protocol) stack 11 and an Ethernet driver 12. These layers convert packets that have been received in accordance with one of the protocols into packets for transmission according to the other of the protocols, and buffer the packets as necessary to accommodate flow control over the links.
FIG. 2 shows the physical architecture of the data processing section 6. The data processing section 6 comprises a data bus 13, such as a PCI (personal computer interface) bus. Connected to the data bus 13 are the Ethernet hardware interface 5, the Fibrechannel hardware interface 4 and the memory bus 14. Connected to the memory bus 14 are a memory unit 15, such as a RAM (random access memory) chip, and a CPU (central processing unit) 16 which has an integral cache 17.
The example of an ISCSI-over-Ethernet packet being received and translated to Fibrechannel will be discussed, in order to explain problems of the prior art. The structure of the Ethernet packet is shown in FIG. 3. The packet 30 comprises an Ethernet header 31, a TCP header 32, an ISCSI header 33 and ISCSI traffic data 34.
Arrows 20 to 22 in FIG. 2 illustrate the conventional manner of processing an incoming Ethernet packet in this system. The Ethernet packet is received by Ethernet interface 5 and passed over the PCI and memory buses 12, 13 to memory 14 (step 20), where it is stored until it can be processed by the CPU 15. When the CPU is ready to process the Ethernet packet it is passed over the memory bus to the cache 16 of the CPU. (Step 21). The CPU processes the packet to perform protocol processing and re-encapsulate the data for transmission over Fibrechannel. The Fibrechannel packet is then passed over the memory bus and the PCI bus to the Fibrechannel interface 4 (step 22), from which it is transmitted. It will be appreciated that this process involves passing the entire Ethernet packet three times over the memory bus 13. These bus traversals slow down the bridging process.
It would be possible to pass the Ethernet packet directly from the Ethernet interface 5 to the CPU, without it first being stored in memory. However, this would require the CPU to signal the Ethernet hardware to tell it to pass the packet, or alternatively for the CPU and the Ethernet hardware to be synchronised, which would be inefficient and could also lead to poor cache performance. In any event, this is not readily possible in current server chipsets.
An alternative process is illustrated in FIG. 4. FIG. 4 is analogous to FIG. 2 but shows different process steps. In step 23 the received Ethernet packet is passed from the Ethernet hardware to the memory 14. When the CPU is ready to process the packet only the header data is passed to the CPU. (Step 24). The CPU process the header data, forms a Fibrechannel header and transmits the Fibrechannel header to the Fibrechannel interface. (Step 25). Then the traffic data 34 is passed to the Fibrechannel hardware (step 26), which mates it with the received header to form a Fibrechannel packet for transmission. This method has the advantage that the traffic data 34 traverses the memory bus only twice. However, this method is not straightforward to implement, since the CPU must be capable of arranging for the traffic data to be passed from the memory 14 to the Fibrechannel hardware in step 26. This is problematic because the CPU would conventionally have received only the headers for that packet, without any indication of where the packet was located in memory, and so it would have no knowledge of where the traffic data is located in the memory. As a result, the CPU would be unable to inform the bridging entity that is to transmit that data onwards of what data is to be transmitted. Furthermore, if that transmitting entity is to be implemented in software then it could be implemented at user level, for example as an application, or as part of the operating system kernel. If it is implemented at user level then it would not conventionally be able to access physical memory addresses, being restricted instead to accessing memory via virtual memory addresses. As a result, it could not access the packet data in memory directly via a physical address. Alternatively, if the transmitting entity is implemented in the kernel then for software abstraction and engineering reasons it would be preferable for it to interface with the network at a high level of abstraction, for instance by way of a sockets API (application programming interface). As a result, it would be preferred that it does not access the packet data in memory directly via a physical address.
One way of addressing this problem is to permit the Ethernet hardware 5 to access the memory 14 by RDMA (remote direct memory access), and for the Ethernet hardware to be allocated named buffers in the memory. Then the Ethernet hardware can write the traffic data of each packet to a specific named buffer and through the RDMA interface with the bridging application (e.g. uDAPL) indicate to the application the location/identity of the buffer which has received data. The CPU can access the data by means of reading the buffer, for example by means of a post( ) instruction having as its operand the name of the buffer that is to be read. The Fibrechannel hardware can then be passed a reference to the named buffer by the application and so (also by RDMA) read the data from the named buffer. The buffer remains allocated to the Ethernet hardware during the reading step(s).
One problem with this approach is that it requires the Ethernet hardware to be capable of accessing the memory 14 by RDMA, and to include functionality that can handle the named buffer protocol. If the Ethernet hardware is not compatible with RDMA or with the named buffer protocol, or if the remainder of the system is not configured to communicated with the Ethernet hardware by RDMA then this method cannot be used. Also, RDMA typically involves performance overheads.
Analogous problems arise when bridging in the opposite direction: from Fibrechannel to ISCSI, and when using other protocols.
There is therefore a need to improve the processing of data units in bridging situations.